1. Field of the Invention
The present invention relates to a method for protecting a user of a target terminal from privacy violation during message exchange between a Secure User Plane Location (SUPL) Location Center (SLC) and an SUPL Positioning Center (SPC).
2. Description of the Related Art
Nowadays, a service using location information of a mobile terminal is increasingly being utilized in a wide range of applications. Meanwhile, various methods for positioning a mobile terminal have been developed. One of these methods is an Internet Protocol (IP) network-based positioning method. In such a positioning method, a mobile terminal may receive information on a Global Positioning System (GPS) satellite from a location server so that it can use an Assisted-Global Positioning System (A-GPS). To this end, the location server carries positioning assistance data of the GPS satellite to the mobile terminal through a data packet of an IP network. Further, the mobile terminal measures location measurement data by using the corresponding positioning assistance data, and carries the location measurement data to the location server through a data packet of the IP network. This method corresponds to a location service using a Secure User Plane Location (SUPL) that is handled by an Open Mobile Alliance Location Working Group (OMA LOC WG).
A location server used in SUPL is called a Secure Location Platform (SLP), and the SLP includes two functional entities, that is, an SUPL Location Center (SLC) and an SUPL Positioning Center (SPC). The SLC receives a request for a location service targeted to a specific mobile terminal (target SUPL Enabled Terminal, hereinafter referred to as “target SET”) from a client, that is, an SUPL Agent, performs authentication and authorization procedures for the client (i.e., SUPL Agent) before positioning the target SET at the request of the client, and checks privacy set in advance by the target SET. Further, the SLP processes charging for the location service and a roaming case of the target SET.
The SPC creates location assistance data to be sent to a target SET, and performs positioning of the target SET by using location measurement data transferred from the target SET. Further, the SPC determines a positioning method (posmethod), which is to be used in the positioning process, with the target SET.
In such a situation where an SLP includes an SLC for managing requests/responses and an SPC for positioning a target SET, an interface for exchanging data exists between the SLC and the SPC. This interface enables a plurality of SLCs to share and use an SPC, and vice versa.
FIG. 1 illustrates a conventional procedure of delivering the real IDentifier (ID) of a target SET to an SPC when an SLP is divided into an SLC and the SPC.
A. An SUPL Agent transmits a Mobile Location Protocol Start Location Immediate Request (MLP SLIR) message, that is, a location service request message, to a Home-SLC (H-SLC, i.e., an SLC included in a Home SLP). The MLP SLIR message includes a mobile station ID (ms-ID, i.e., ID of a target SET), a client-ID (i.e., ID of the SUPL Agent), and Quality of Position (QoP) of the requested location service.
B. The H-SLC determines if the target SET is roaming.
C. The H-SLC transmits a Positioning Request (PREQ) message to a Home-SPC (H-SPC, i.e., an SPC included in a Home SLP). The PREQ message includes a session-ID and a posmethod. The session-ID includes of an SLC session-ID and an SET session-ID. The H-SLC creates the SLC session-ID by using its own ID and a unique number for identifying a session in progress by the SLC. The H-SLC completes the session-ID while leaving the SET session-ID empty. The H-SLC transmits posmethod, which is information on a positioning method to be used this time, to the H-SPC. The posmethod represents a protocol to be used for positioning and a positioning type. Details of the posmethod are the same as those of a posmethod specified in the OMA TS ULP V2—0 standard, which is hereby incorporated by reference.
D. The H-SPC acquires the session-ID and the posmethod from the H-SLC as in step C. Further, the H-SPC transmits a Positioning Response (PRES) message accepting the positioning request to the H-SLC.
E. The H-SLC informs the target SET of the positioning request by transmitting an SUPL Initiation (SUPL INIT) message thereto. The SUPL INIT message includes the session-ID created in step D, the posmethod, and an SLP mode, which is specified in the OMA TS ULP V2—0 standard, representing whether a positioning process follows a proxy mode or a non-proxy mode. The proxy mode refers to a mode used when an H-SLC and H-SPC are integrated into an H-SLP, and the non-proxy mode refers to a mode used when an H-SLP is divided into an H-SLC and an H-SPC.
F. The target SET attempts to connect data communication.
G. The target SET transmits an SUPL Positioning Initiation (SUPL POS INIT) message to the H-SLP. The SUPL POS INIT message includes SET capability including information on positioning methods supportable by itself, and a Location ID (LID, e.g., cell ID) representing currently existing network information. Just at this moment, the target SET fills the SET session-ID included in the session-ID with its own real ID. Here, the real ID is unique information for recognizing a target SET on a network or identifying a target SET from other SETs. For example, the real ID may be an International Mobile Subscriber Identity (IMSI) value or a Mobile Station International Integrated Services Digital Network (MSISDN) value. Further, the real ID may be a unique IP address assigned to a target SET.
H. The H-SLC transmits the SUPL POS INIT message created in step G to the H-SPC through Positioning Data (PDATA). In this way, the H-SPC receives the real ID of the target SET.
I. (optional step) If the H-SPC cannot create a coarse position by using the LID of the SUPL POS INIT message included in the PDATA, it transmits a request for the coarse position to the H-SLC by returning the LID through a Positioning LID Request (PLREQ) message. Here, the coarse position refers to information about an actual geographic region corresponding to network information, such as an LID (e.g., place-name information for a current location, such as Seoul, Incheon, etc. or Gangnam-gu, Gangbuk-gu, etc.).
J. (optional step) Upon receiving the PLREQ message as in step I, the H-SLC creates a coarse position based on the returned LID, and then transmits the created coarse position to the H-SPC.
K. The target SET performs a positioning process with the H-SPC and the H-SLC. Details of the positioning process are the same as those of an SUPL POS (SUPL Positioning) specified in the OMA LOC AD SUPL V2—0 standard.
L. Upon completing positioning of the target SET, the H-SPC transmits PDATA, including an SUPL END message to be sent to the target SET, to the H-SLC.
M. The H-SLC transmits the SUPL END message to the target SET.
N. The H-SPC transmits a positioning result (posresult) to the H-SLC.
O. The H-SLC transmits the posresult to the SUPL Agent.
The fact that an SLC and an SPC are separated means that the SLC and the SPC may be managed by different network operators (e.g., mobile communication providers). For example, a network operator manages only an SLC, and an SPC may exist on an external network. In such a case, if the SLC transfers the real ID (e.g., MSISDN, IMSI, IP ADDRESS) of a target SET to the SPC, there is a risk that the current location of the target SET is exposed. That is, if the location information and real ID of a target SET are simultaneously exchanged between the SLC and the SPC, there is a problem in that the privacy of the target SET is violated.
In general, a user of a target SET does not make a contract with an SPC of an SLP, but makes a contract with an SLC for location service rights. Also, since the real ID of the user of a target SET is connected directly with his/her own privacy, he/she does not want his/her real ID to be transmitted to entities other than an SLC. Moreover, an SPC does not necessarily require the real ID of a target SET. This is because an SPC has only to identify a plurality of positioning requests input therein and appropriately respond to a corresponding request.